The use of a Certificate Authority (CA) to distribute a public key of a public key/private key pair is well known. A CA distributes public keys by creating and issuing certificates, documents which bind identifying information about a user with the user's public key. Certificates also typically have information about the time period for which they are valid. The public key, the identifying information, the lifetime information, and other information such as a serial number are signed with the CA's private key. The lifetime information, the identifying information, the user's public key, and the signature together form the certificate. Once a user has been issued a certificate, it can be used by anyone who requires his public key; the user can present the certificate to another party or the certificate can be stored in a database and retrieved by the party requiring the certificate. Provided that the other users on the system have valid copies of the CA's public key, a user's public key can be validated by verifying the signature on the certificate with the CA's public key.
Several revocation methods exist to mitigate against the compromise of the private key of a public key/private key pair and to allow a user's authority to use a public key/private key pair to be taken away. One revocation method allows a certificate to be revoked. The CA may publish a certificate revocation list (CRL) containing the serial numbers of the revoked certificates and signed with the CA's private key; the validating party then downloads the CRL and verifies that a certificate is not in the CRL when validating the public key. Typically a CRL has a certain validity period and periodically new CRLs are generated. Another revocation method is to use an online certificate status protocol (OCSP) where the validating party communicates with a trusted online entity that confirms that a certificate has not been revoked. Yet a third revocation method is to use short-lived certificates. With this approach, a CA frequently issues a certificate with a short lifetime. A user retrieves his certificate from the CA after it is generated and presents the latest short-lived certificate to the validating party. If certification is to be revoked, the CA does not issue further short-lived certificates. Since the current certificate is short-lived, it will soon expire and it will no longer be possible to validate the public key using the certificate. The short-lived certificate makes it possible for the validating party to accept a certificate with no further checking.
Current revocation methods are not well suited to an environment where neither the presenter of a certificate nor the validating party has a constant connection to the CA or another online entity. An example of such an environment would be two wireless devices communicating solely with one another using Bluetooth wireless technology. For example, if CRLs are used, a device that needs to validate a certificate may be unable to download the appropriate CRL from the CA because it lacks a connection to the Internet. OCSP requires an online check that may not be possible. Short-lived certificates are promising in this environment in that they do not require an online check at the time the certificate is validated, but fetching a new short-lived certificate presents a problem when there is no connection to the CA.
It should be noted that checks of certificate revocation are not currently widely deployed in the wired internet. Server certificates sent to clients have been widely deployed, but client certificates sent to servers have not. As a web server is typically in a secure location and typically uses a costly secure hardware token for private key storage and signing, there is currently a certain degree of built-in security that lessens the need to check for certificate revocation. However for the scenario of one low-cost wireless device presenting a certificate to another low-cost wireless device, the ability to check for certificate revocation becomes more important. In this scenario, it may be too costly to use a secure hardware token and there is also less physical security because the devices may not be in a secure location.
An object of the present invention is to obviate or mitigate the above disadvantages and provide a method and apparatus to facilitate certificate revocation checks between two wireless devices where neither has a constant online connection.